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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The objective of this document is to address the Inter-IMS Network to Network Interface (II-NNI) consisting of Ici and 
Izi reference points between IMS networks in order to support end-to-end service interoperability. 

The present document will address the issues related to control plane signalling (3GPP usage of SIP and SDP protocols, 
required SIP header fields) as well as other interconnecting aspects like security, numbering/naming/addressing and 
user plane issues as transport protocol, media and codecs actually covered in a widespread set of 3GPP specifications. A 
profiling of the Inter-IMS Network to Network Interface (II-NNI) is also provided. 

Charging aspects will be addressed as far as SIP signalUng is concerned. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP 
TR 21.905 [1]. 

example: text used to clarify abstract rules by applying them literally. 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions, as specified in 3GPP TS 22.228 [9]. 

IP multimedia session: as specified in 3GPP TS 22.228 [9] an IP multimedia session is a set of multimedia senders and 
receivers and the data streams flowing from senders to receivers. IP multimedia sessions are supported by the IP 
multimedia CN Subsystem and are enabled by IP connectivity bearers (e.g. GPRS as a bearer). A user can invoke 
concurrent IP multimedia sessions. 

non-roaming II-NNI: the II-NNI between IMS home networks. 

roaming II-NNI: the II-NNI between a visited IMS network and the IMS home network. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.292 [120] apply: 

MSC Server enhanced for ICS 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Ici Reference Point between an IBCF and another IBCF or I-CSCF belonging to a different IM CN 

subsystem network 
Izi Reference Point between a TrGW and another TrGW or media handling node belonging to a 

different IM CN subsystem network 
Mi Reference Point between a BGCF and CSCF 

Mm Reference Point between a CSCF/BGCF/IMS ALG and an IP multimedia network. 

Mw Reference Point between a CSCF and another CSCF 

Mx Reference Point between a CSCF/BGCF/MSC Server enhanced for ICS and IBCF 

3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPP TR 21.905 [1]. 

ACR Anonymous Communication Rejection 

B2BUA Back 2 Back User Agent 

BGCF Breakout Gateway Control Function 

CAT Customized Alerting Tone 

CB Communication Barring 

CCBS Completion of Communications to Busy Subscriber 

CCNR Communication Completion on No Reply 

CDIV Communication Diversion 

CDIVN Communication Diversion Notification 

CRS Customized Ringing Signal 

ECT Explicit Communication Transfer 

FA Flexible Alerting 

HOLD Communication HOLD 

CW Communication Waiting 
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IBCF Interconnection Border Control Function 

ICB Incoming Communication Barring 

ICS IMS Centralized Services 

I-CSCF Interrogating CSCF 

II-NNI Inter-IMS Network to Network Interface 

IM Instant Messaging 

IMS-ALG IMS Application Level Gateway 

MCID Malicious Communication IDentification 

MRFC Media Resource Function Controller 

MSRP Message Session Relay Protocol 

MWI Message Waiting Indication 

NA(P)T-PT Network Address (Port-Multiplexing) Translation-Protocol Translation 

NNI Network to Network Interface 

OCB Outgoing Communication Barring 

OIP Originating Identification Presentation 

OIR Originating Identification Restriction 

P-CSCF Proxy CSCF 

PNM Personal Network Management 

PRES Presence 

TIP Terminating Identification Presentation 

TIR Terminating Identification Restriction 

TrGW Transition Gateway 



Overview 



Interconnection between two different IM CN subsystems shall be guaranteed in order to support end-to-end service 
interoperability. For this purpose, Inter-IMS Network to Network Interface (II-NNI) between two IM CN subsystem 
networks is adopted, according to the assumptions coming from 3GPP TS 23.002 [3] and 3GPP TS 23.228 [4]. 

Aiming to support the delivery of IMS services between two separated IM CN subsystems, protocol interconnection has 
to occur: 

• at a control plane level, in order that IMS procedures can be supported. In this case the adopted reference point 
is the Ici; and 

• at a user plane level, where media streams are exchanged over the Izi reference point. 

The management of IP multimedia sessions is acted by using SIP. The transport mechanism for both SIP session 
signalling and media transport is IPv4 (IETF RFC 791 [2]) or IPv6 (IETF RFC 2460 [7]). The 3GPP profile of SIP 
defining the usage of SIP within the IM CN subsystem is specified in 3GPP TS 24.229 [5]. Example call flows are 
provided in 3GPP TR 24.930 [6]. 

The general interconnection model is shown in Figure 4.1. 




II-NNI 




Figure 4.1 : Interconnection IVIodel for IM CN subsystems 

The possible functional entities involved in the signalling plane interconnection (IBCF, I-CSCF, P-CSCF, BGCF and 
MSC Server enhanced for ICS) and in the user plane interconnection (TrGW) are specified in 3GPP TS 24.229 [5], in 
3GPP TS 24.292 [121] and in 3GPP TS 29.162 [8]. 

IP Version interworking is described within 3GPP TS 29.162 [8]. 
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Reference model for interconnection between IIVI CN 
subsystems 



5.1 



General 



Figure 5.1 illustrates the architecture diagram given in 3GPP TS 23.228 [4] showing the Inter-IMS Network to Network 
Interface (11-NNI) between two IM CN subsystem networks. 



P-CSCF 



MSC Server 

enhanced 

for ICS 




S-CSCFl 

7 



^ ^Mx 



^ 


P-CSCF 


^ 


Mx 






> 


MSC Server 

enhanced 

for ICS 





Signalling 

^^ IM CN subsystem network A IM CN subsystem network B 

Figure 5.1.1 : Inter-IMS Network to Network Interface between two IM CN subsystem networks 

The protocols over the two reference points Ici and Izi make up the Inter-IMS Network to Network Interface. 

The Ici reference point allows IBCFs to communicate with each other in order to provide the communication and 
forwarding of SIP signalling messaging between IM CN subsystem networks. The Izi reference point allows TrGWs to 
forward media streams between IM CN subsystem networks. 

IMS roaming performed by using II-NNI is considered, when the IBCFs are inserted at the network borders. 

Whenever the Inter-IMS Network to Network Interface is used to interconnect two IM CN subsystem networks 
belonging to different security domains, security procedures apply as described in 3GPP TS 33.210 [10]. 



5.2 Functionalities performed by entities at the edge of the 
network 

5.2.1 Interconnection Border Control Function (IBCF) 

An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection 
between IM CN subsystem networks by using Ici reference point. According to 3GPP TS 23.228 [4], IBCF can act both 
as an entry point and as an exit point for a network. 

The functionalities of IBCF are indicated in the 3GPP TS 23.228 [4] and specified in 3GPP TS 24.229 [5]. They 
include: 

• network topology hiding; 

• application level gateway (for instance enabling communication between IPv6 and IPv4 SIP applications, or 
between a SIP application in a private IP address space and a SIP application outside this address space); 

• controlling transport plane functions; 

• controlling media plane adaptations; 
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• screening of SIP signalling information; 

• selecting the appropriate signalling interconnect; and 

• generation of charging data records. 

Based on local configuration, the IBCF performs transit routing functions as specified in 3GPP TS 24.229 [5]. 
The IBCF acts as a B2BUA when it performs IMS-ALG functionaUty. 

5.2.2 Transition Gateway (TrGW) 

According to 3GPP TS 23.002 [3], the TrGW is located at the network borders within the media path and is controlled 
by an IBCF. Forwarding of media streams between IM CN subsystem networks is applied over Izi reference point. 

The TrGW provides functions like network address/port translation and IPv4/IPv6 protocol translation. NAT-PT binds 
addresses in IPv6 network with addresses in IPv4 network and vice versa to provide transparent routing between the 
two IP domains without requiring any changes to end points. NA(P)T-PT provides additional translation of transport 
identifier (TCP and UDP port numbers). The approach is similar to that one described also in 3GPP TS 29.162 [8]. 

Further details are described in 3GPP TS 23.228 [4]. 

6 Control plane interconnection 

6.1 Definition of Inter-IMS Network to Network Interconnection 

6.1 .1 SIP metliods and lieader fields 

6.1.1.1 General 

The functional entity closest to the border of an II-NNI (see reference model in Clause 5) shall provide the capabilities 
specified for that network element in Annex A. 2 of 3GPP TS 24.229 [5] with modifications as described in the 
following sub-clauses. 

6.1.1.2 SIP methods 

3GPP TS 24.229 [5] defines the methods allowing an IBCF to interconnect to an IBCF placed in another IM CN 

subsystem. 

The following SIP methods are supported on the II-NNI as defined in table 6.1. 

The following table is based on Table A. 5 and Table A. 163 of 3GPP TS 24.229 [5] and endorsed for this document: 
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Table 6.1 : Supported SIP methods 



Item 


Method 


Ret. 


ll-NNI 


Sending 


Receiving 


1 


ACK request 


[13] 


m 


m 


2 


BYE request 


[13] 


m 


m 


3 


BYE response 


[13] 


m 


m 


4 


CANCEL request 


[13] 


m 


m 


5 


CANCEL response 


[13] 


m 


m 


5A 


INFO request 


[28] 








5B 


INFO response 


[28] 








8 


INVITE request 


[13] 


m 


m 


9 


INVITE response 


[13] 


m 


m 


9A 


MESSAGE request 


[19] 








9B 


MESSAGE response 


[19] 








10 


NOTIFY request 


[20] 


Cl 


cl 


11 


NOTIFY response 


[20] 


Cl 


cl 


12 


OPTIONS request 


[13] 


m 


m 


13 


OPTIONS response 


[13] 


m 


m 


14 


PRACK request 


[18] 


m 


m 


15 


PRACK response 


[18] 


m 


m 


15A 


PUBLISH request 


[21] 


cl 


cl 


15B 


PUBLISH response 


[211 


cl 


cl 


16 


REFER request 


[22] 








17 


REFER response 


[22] 








18 


REGISTER request 


[13] 


c2 


c2 


19 


REGISTER response 


[13] 


c2 


c2 


20 


SUBSCRIBE request 


[201 


cl 


cl 


21 


SUBSCRIBE response 


[201 


cl 


cl 


22 


UPDATE request 


[23] 


m 


m 


23 


UPDATE response 


[23] 


m 


m 


c1 : In case of roaming scenario, tlie support of tlie metliod is m, else o. 
c2: In case of roaming scenario, the support of the method is m, else n/a. 


NOTE: In the above table, m, o and c and n/a have the meanings indicated in 
Table 6.3 



6.1.1.3 



SIP header fields 



6.1.1.3.0 



General 



The IBCF shall provide the capabilities to manage and modify SIP header fields according to section 5.10 and Annex A 
of 3GPP TS 24.229 [5] with modifications as described in the following sub-clauses. 



6.1.1.3.1 



Trust and no trust relationship 



The IBCF acting as exit point applies the procedures described in clause 5. 10.2 of 3GPP TS 24.229 [5] before 
forwarding the SIP signalling to the IBCF acting as entry point. The IBCF acting as entry point applies the procedures 
described in clause 5.10.3 of 3GPP TS 24.229 [5]. 

Additionally, in case there is no trust relationship between the two IM CN subsystems connected by II-NNI, the IBCF 
acting as exit point applies the procedures described in clause 4.4 of 3GPP TS 24.229 [5], before forwarding the SIP 
signalling to the next IBCF acting as an entry point. The IBCF acting as an entry point applies the procedures described 
in the section 5.10.3 of 3GPP TS 24.229 [5]. 

These procedures may be utilized on a per header field basis to realize overall trust as well as per service level screening 
of header fields. Trust relationships and trust domains may be defined by inter-operator agreements for individual 
services and/or individual SIP header fields. 

The management of the SIP header fields (if present) over II-NNI in case of a presence or not of a trust relationship 
between the two interconnected IM subsystems is wrapped up in the following table. 
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Table 6.2: Management of SIP header fields over ll-NNI in presence or not of a trust relationship 



Item 


Header field 


Trust relationship 


Not trust relationship 


1 


P-Asserted-ldentity 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
and Annex J. 2 


As specified in 3GPP TS 
24.229 [5], clause 4.4 and 
Annex J. 2 


2 


P-Access-Network- 1 nfo 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


3 


Resource-Priority 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


4 


History-Info 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in Clause 4.3.3 of 
RFC 4244 [25] and in 3GPP 
TS 24.229 [5], clause 4.4 


5 


P-Asserted-Service 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 
(NOTE 3) 


6 


P-Charging-Vector (see RFC 3455 [24]) 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


7 


P-Charging-Function-Addresses (see 
RFC 3455 [24]) 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


As specified in 3GPP TS 
24.229 [5], clause 5.10 


8 


P-Profile-Key 
(NOTE 2) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


9 


P-Private-Network-lndication 
(N0TE1) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


10 


P-Served-User 
(NOTE 1 , NOTE 2) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


11 


Reason (in a response) 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


12 


P-Early-Media 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


As specified in 3GPP TS 
24.229 [5], clause 4.4 


NOTE 1 : For a roaming ll-NNI between a home IMS and a visited IIVIS, a trust relationship with respect to this 

header field is required. 
NOTE 2: This header field is only applicable on an ll-NNI between a home IMS and a visited IMS. 
NOTE 3: In addition, value-dependent operator policies may be applied. 



6.1.1.3.2 



Derivation of applicable SIP header fields from 3GPP TS 24.229 [5] 



For any method in Table 6.1, the SIP header fields applicable on the II-NNI are detailed in the corresponding method 
tables for the UA role and proxy role sending behaviour in Annex A of 3GPP TS 24.229 [5]. Unless other information 
is specified in the normative part of the present specification, the applicability of header fields at the II-NNI can be 
derived for each method from the corresponding tables in Annex A of 3GPP TS 24.229 [5] as follows: 

All header fields not present in the corresponding tables in Annex A of 3GPP TS 24.229 or marked as "n/a" in 
both the "RFC status" and "profile status" columns for the UA role and proxy role sending behaviour of that 
tables are not applicable at the II-NNI. 

NOTE 1 : Operators could choose to apply header fields for new SIP extensions on an II-NNI based on bilateral 
agreements, but this is outside the scope of the present specification. 

All header fields which are marked as "o" in at least one of the "RFC status" or the "profile status" profile 
columns for the sending behaviour in the corresponding UA role and proxy role tables in Annex A of 3GPP TS 
24.229 [5] and as "n/a" or "o" in the other such columns are applicable at II-NNI based on bilateral agreement 
between operators. 
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All header fields which are marked as "m" in at least one of the "RFC status" or the "profile status" columns for 
the sending behaviour in the corresponding UA role or proxy role table in Annex A of 3GPP TS 24.229 [5] and 
as "n/a", "o", or "m" in the other such columns are applicable at the II-NNI. 

- If conditions are specified, they are also appUcable at the II-NNI and the above rules are applicable to the "n/a", 
"o" and "m" values within the conditions. 

NOTE 2: In the above rules, the RFC profile columns are taken into account in order to enable interworking with 
non-3GPP networks. 

An informative summary of SIP header fields to be used over the II-NNI is proposed in Annex A. 

6.1 .1 .3.3 Applicability of SIP header fields on a roaming II-NNI between home IMS and 
visited IMS 

The following SIP header fields are only applicable on a roaming II-NNI between a home IMS and a visited IMS: 

Proxy- Authenticate 

Proxy- Authorization 

6.1 .1 .3.4 Applicability of SIP header fields on an II-NNI between home IMS networks 

The following SIP header fields are not applicable on an II-NNI between home IMS networks: 

- P-Called-Party-ID 
P-Preferred-Service 

- P-Profile-Key 
P-Served-User 

- P-Visited-Network-ID 

- www-Authenticate 

6.1.1.4 Notations of the codes 

In the table 6.1 the status codes "m", "o", "c" and "n/a" have the following meanings: 
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Table 6.3: Key to notation codes for SIP messages 



Notation 
code 


Notation name 


Sending side 


Receiving side 


m 


mandatory 


The message shall be supported at II- 
NNI. 

Supporting sending a SIP message at 
the ll-NNI means that this message shall 
be sent over the ll-NNI if received from 
the serving network. It does not imply 
that network elements inside the serving 
network or user equipment connected to 
this network shall support this message. 


Supporting receiving a SIP message at 
the ll-NNI means that this message shall 
be forwarded to the serving network. It 
does not imply that network elements 
inside the served network or user 
equipment connected to this network are 
supporting this message. 





optional 


The message may or may not be 
supported at ll-NNI. The support of the 
method is provided based on bilateral 
agreement between the operators. 


Same as for sending side. 


n/a 


not applicable 


It is impossible to use/support the 
message. 


It is impossible to use/support the 
message. This message will be 
discarded by the IBCF. 


c 
<integer> 


conditional 


The requirement on the message ("m", 
"o" or "n/a") depends on the support of 
other optional or conditional items. 
<integer> is the identifier of the 
conditional expression. 


Same as for sending side. 



6.1.1.5 



Modes of signalling 



Overlap signalling may be used if agreement exists between operators to use overlap and which method to be used, 
otherwise enbloc shall be used at the II-NNI. 



6.1.2 SDP protocol 



6.1.2.1 



General 



The functional entity closest to the border of an II-NNI (see reference model in Clause 5) shall provide the capabilities 
specified for that network element in Annex A. 3 of 3GPP TS 24.229 [5]. 

6.1.3 Major capabilities 

This subclause contains the major capabilities to be supported over the II-NNI. 

The table 6.1.3.1 specifies which capabilities are applicable for II-NNI. The profile status codes within table 6.1.3.1 are 
defined in table 6.1.3.2. 

For the "Basic SIP" capabilities part of table 6.1.3.1, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the IETF RFC 3261 [13] main mechanisms described in the 2"** column "Capability over the 
Ici". 

For the "Extensions to basic SIP" capabilities part, the last column "Profile status over II-NNI" specifies the general 
status of applicability of the RFC referenced in the 2"'' column "Capability over the Ici". 

If necessary, the applicability of RFCs at the II-NNI level is further detailed in the present Technical Specification. 

The columns "Reference item in 3GPP TS 24.229 [5] for the profile status" provide informative references for 
comparison purposes into the UA and Proxy role major capabilities tables in 3GPP TS 24.229 [5], where the 
capabilities are defined via additional references. 
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Table 6.1.3.1 : Major capabilities over ll-NNI 



Item 


Capability over the lei 


Reference item in 3GPP 

TS 24.229 [5] for the 

profile status 


Profile 

status over 

ll-NNI 


UA Role 
(N0TE1) 


Proxy role 
(NOTE 2) 




Basic SIP (IETF RFC 3261 [13]) 








1 


registrations 


1,2, 2A 


- 


c2 


2 


initiating a session 


2B, 2C, 3,4 


- 


m 


3 


terminating a session 


5 


3 


m 


4 


General proxy behaviour 


- 


4,5, 14, 15, 
19F 


n/a 


5 


Forking of initial requests 


9,10 


6 


m 


6 


support of indication of TLS connections in the Record-Route 
header 


- 


7,8 


n/a 


7 


usage of http authentication 


7, 8, 8A 


8A 


c2 


8 


Timestamped requests (Timestamp header field) 


6 


- 


m 


9 


Presence of date in requests and responses (Date header 
field) 


11 


9 


m 


10 


Presence of alerting information data (Alert-info header field) 


12 


10 





11 


Support and handling of the Require header field for 
REGISTER and other requests or responses for methods 
other than REGISTER 




11, 12, 13 


m 


12 


Support and reading of the Supported and Unsupported 
header fields 


- 


16, 17, 18 


m 


13 


Support of the Error-Info header field in 3xx - 6xx responses 


- 


19 





14 


Support and handling of the Organization header field 


- 


19A, 19B 


m 


15 


Support and handling of the Gall-Info header field 


- 


19C, 19D 


m 


16 


Support of the Contact header field in 3xx response 


- 


19E 


m 




Extensions to basic SIP 








17 


draft-ietf-sipcore-info-events-08 [39]: SIP INFO method and 
package framework 


13 


20 





17A 


draft-ietf-sipcore-info-events-08 [39]: legacy INFO usage 


13A 


20A 





18 


IETF RFC 3262 [18]: reliability of provisional responses in 
SIP (PRACK method) 


14 


21 


m 


19 


IETF RFC 3515 [22]: the SIP REFER method 


15 


22 





20 


IETF RFC 3312 [40] and RFC 4032 [41]: integration of 
resource management and SIP (Preconditions framework) 


16 


23 





21 


IETF RFC 331 1 [23]: the SIP UPDATE method 


17 


24 


m 


22 


IETF RFC 3313 [42]: SIP extensions for media authorization 
(P-Media-Authorization header field) 


19 


26 


n/a 


23 


IETF RFC 3265 [20]: SIP specific event notification 
(SUBSCRIBE/NOTIFY methods) 


20,21,22, 
23 


27,28 


Cl 


24 


IETF RFC 3327 [43]: session initiation protocol extension 
header field for registering non-adjacent contacts (Path 
header field) 


24 


29 


c2 


25 


IETF RFC 3325 [44]: private extensions to the Session 
Initiation Protocol (SIP) for network asserted identity within 
trusted networks 


25 


30 


c4 


26 


IETF RFC 3325 [44]: the P-Preferred-ldentity header field 
extension 


- 


- 


n/a 


27 


IETF RFC 3325 [44]: the P-Asserted-ldentity header field 
extension 


- 


- 


c4 


28 


IETF RFC 3323 [34]: a privacy mechanism for the Session 
Initiation Protocol (SIP) (Privacy header field) 


26, 26A, 
26B, 26C, 
26D, 26E, 
26F, 26G, 
26H 


31, 31 A, 
31B, 31C, 
31D, 31E, 
31F, 31G, 
31H 


m 


29 


IETF RFC 3428 [19]: a messaging mechanism for the 
Session Initiation Protocol (SIP) (MESSAGE method) 


27 


33 





30 


IETF RFC 3608 [45]: session initiation protocol extension 
header field for service route discovery during registration 
(Service-Route header field) 


28 


32 


c2 


31 


IETF RFC 3486 [46]: compressing the session initiation 
protocol 


29 


34 


n/a 


32 


IETF RFC 3455 [24]: private header extensions to the 


30 


35 
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session initiation protocol for the 3rd-Generation Partnership 
Project (3GPP) 








32A 


IETF RFC 3325: act as first entity within the trust domain for 
asserted identity 


30A 


30A 


n/a 


328 


IETF RFC 3325: act as entity within trust network that can 
route outside the trust network 


30B 


30B 


n/a 


32C 


IETF RFC 3325: act as entity passing on identity 
transparently independent of trust domain 


30C 


30C 


n/a 


33 


IETF RFC 3455 [24]: the P-Associated-URI header field 
extension 


31 


36 


c2 


34 


IETF RFC 3455 [24]: the P-Called-Party-ID header field 
extension 


32 


37 


c2 


35 


IETF RFC 3455 [24]: the P-Visited-Network-ID header field 
extension 


33 


38,39 


c2 


36 


IETF RFC 3455 [24]: the P-Access-Network-lnfo header field 
extension 


34 


41,42,43 


c4 


37 


IETF RFC 3455 [24]: the P-Charging-Function-Addresses 
header field extension 


35 


44, 44A 


n/a 


38 


IETF RFC 3455 [24]: the P-Charging- Vector header field 
extension 


36 


45,46 


c2 


39 


IETF RFC 3329 [47]: security mechanism agreement for the 
session initiation protocol 


37 


47 


n/a 


39A 


draft-dawes-dispatch-mediasec-parameter-02 [134]: 
mediasec header field parameter for marking security 
mechanisms related to media 


37A 


47A 


n/a 


40 


IETF RFC 3326 [48]: the Reason header field for the session 
initiation protocol 


38 


48 





41 


draft-jesske-dispatch-reason-in-responses-02 [49]: use of the 
Reason header field in Session Initiation Protocol (SIP) 
responses 


38A 


48A 


c4 


42 


IETF RFC 3581 [50]: an extension to the session initiation 
protocol for symmetric response routeing 


39 


49 





43 


IETF RFC 3841 [51]: caller preferences for the session 
initiation protocol (Accept-Contact, Reject-Contact and 
Request-Disposition header fields) 


40, 40A, 
40B, 40C, 
40D, 40E, 
40F 


50, 50A, 
50B, 50C, 
50D, 50E, 
50F 


m 


44 


IETF RFC 3903 [21]: an event state publication extension to 
the session initiation protocol (PUBLISH method) 


41 


51 


Cl 


45 


IETF RFC 4028 [52]: SIP session timer (Session-Expires and 
Min-SE headers) 


42 


52 


m 


46 


IETF RFC 3892 [53]: the SIP Referred-By mechanism 


43 


53 


m 


47 


IETF RFC 3891 [54]: the Session Initiation Protocol (SIP) 
"Replaces" header 


44 


54 





48 


IETF RFC 391 1 [55]: the Session Initiation Protocol (SIP) 
"Join" header 


45 


55 





49 


IETF RFC 3840 [56]: the callee capabilities 


46 


56 





50 


IETF RFC 4244 [25]: an extension to the session initiation 
protocol for request history information (History-Info header 
field) 


47 


57 





51 


IETF RFC 5079 [57]: Rejecting anonymous requests in the 
session initiation protocol 


48 


58 





52 


IETF RFC 4458 [58]: session initiation protocol URIs for 
applications such as voicemail and interactive voice 
response (NOTE 3) 


49 


59 





53 


IETF RFC 4320 [59]: Session Initiation Protocol's (SIP) non- 
INVITE transactions 


50 


61 


m 


54 


IETF RFC 4457 [60]: the P-User-Database private header 
field extension 


51 


60 


n/a 


55 


IETF RFC 5031 [61]: a uniform resource name for services 


52 


62 


n/a 


56 


IETF RFC 5627 [62]: obtaining and using GRUUs in the 
Session Initiation Protocol (SIP) 


53 


63 


cl 


57 


draft-patel-dispatch-cpc-oli-parameter-03 [63]: an extension 
to the session initiation protocol for request cpc information 


54 


64 


c4 


58 


IETF RFC 4168 [27]: the Stream Control Transmission 
Protocol (SCTP) as a Transport for the Session Initiation 
Protocol (SIP) 


55 


65 





59 


IETF RFC 5002 [64]: the SIP P-Profile-Key private header 


56 


66, 66A, 


c3 
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field extension 




66B 




60 


IETF RFC 5626 [65]: managing client initiated connections in 
SIP 


57 


67 


Cl 


61 


IETF RFC 5768 [66]: indicating support for interactive 
connectivity establishment in SIP 


58 


- 


n/a 


62 


IETF RFC 5365 [67]: multiple-recipient IVIESSAGE requests 
in the session initiation protocol 


59 


69 


if 29, else 

n/a 


63 


draft-ietf-sipcore-location-conveyance-03 [68]: SIP location 
conveyance (Geolocation header) 


60 


70, 70A, 
708 


m 


64 


IETF RFC 5368 [69]: referring to multiple resources in the 
session initiation protocol 


61 


71 


if 19, else 
n/a 


65 


IETF RFC 5366 [70]: conference establishment using 
request-contained lists in the session initiation protocol 


62 


72 





66 


IETF RFC 5367 [71]: subscriptions to request-contained 
resource lists in the session initiation protocol 


63 


73 


if 23, else 
n/a 


67 


IETF RFC 4967 [72]: dialstring parameter for the session 
initiation protocol uniform resource identifier 


64 


74 


c2 


68 


IETF RFC 4964 [73]: the P-Answer-State header extension 
to the session initiation protocol for the open mobile alliance 
push to talk over cellular 


65 


75 





69 


IETF RFC 5009 [74]: the SIP P-Early-IVIedia private header 
field extension for authorization of early media 


66 


76 


m 


70 


IETF RFC 4694 [75]: number portability parameters for the 
"tel" URI 


67, 67A, 
67B 


77, 77A, 
77B 





71 


draft-yu-tel-dai-09 [76]: DAI Parameter for the 'tel' URI 


68 


78 





72 


IETF RFC 441 1 [77]: extending the session initiation protocol 
Reason header for preemption events 


69 


79 





73 


IETF RFC 4412 [78]: communications resource priority for 
the session initiation protocol? (Resource-Priority header 
field) 


70, 70A, 
708, 70C, 
70D, 70E, 
70F, 70G 


80, 80A, 
80B, 80C, 
80D, 80E, 
80F, 80G 





74 


IETF RFC 5393 [79]: addressing an amplification 
vulnerability in session initiation protocol forking proxies 


71 


81 


m 


75 


IETF RFC 5049 [80]: the remote application identification of 
applying signalling compression to SIP 


72 


82 


n/a 


76 


IETF RFC 5688 [81]: a session initiation protocol media 
feature tag for MIME application sub-types 


73 


83 


cl 


77 


draft-drage-sipping-service-identification-04 [26]: 
Identification of communication services in the session 
initiation protocol 


74 


84, 84A 





78 


IETF RFC 5360 [82]: a framework for consent-based 
communications in SIP? 


75, 75A, 
75B 


85 





79 


draft-johnston-sipping-cc-uui-09 [83]: transporting user to 
user information for call centers using SIP? 


76 


86 


cl 


80 


draft-vanelburg-dispatch-private-network-ind-01 [84]: The 
SIP P-Private-Network-lndication private-header (P-Header) 


77 


87 


cl 


81 


IETF RFC 5502 [85]: the SIP P-Served-User private header 


78 


88 


c2 


83 


draft-dawes-sipping-debug-02 [87]: the P-Debug-ID header 
extension 


80 


90 





84 


draft-ietf-sipcore-1 99-02 [88]: the 199 (Early Dialog 
Terminated) response code) 


81 


91 


m 


85 


IETF RFC 5621 [89]: message body handling in SIP 


82 


92 


m 


86 


draft-holmberg-sip-keep-04 [90]: indication of support for 
keep-alive 


83 


93 





87 


IETF RFC 5552 [91]: SIP Interface to VoiceXML Media 
Services 


84 


94 


n/a 


88 


IETF RFC 3862 [92]: common presence and instant 
messaging (CPIM): message format 


85 


95 





89 


IETF RFC 5438 [93] : instant message disposition notification 


86 


96 





90 


IETF RFC 5373 [94]: requesting answering modes for SIP 
(Answer-Mode and Priv-Answer-Mode header fields) 


87 


97, 97A 





91 


draft-patel-ecrit-sos-parameter-09 [95]: SOS URI parameter 
for marking SIP requests related to emergency calls 


88 


98 


n/a 


92 


IETF RFC 3959 [96]: the early session disposition type for 
SIP 


89 


99 





93 


draft-rosenberg-sipcore-target-uri-delivery-01 [97]: delivery of 
Request-URI targets to user agents 


90 


100 


n/a 
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94 


draft-kaplan-sip-session-id-02 [124]: The Session-ID header 


91 


101 





95 


draft-ietf-sipcore-invfix-01 [125]: correct transaction handling 
for 200 responses to Session Initiation Protocol INVITE 
requests 


92 


102 


m 


96 


IETF RFC 5658 [126]: addressing Record-Route issues in 
the Session Initiation Protocol (SIP) 


93 


103 





97 


draft-ietf-sip-ipv6-abnf-fix-05 [127]: essential correction for 
IPv6 ABNF and URI comparison in IETF RFC 3261 [13] 


94 


104 


m 


98 


IETF RFC 4488 [132]: suppression of session initiation 
protocol REFER method implicit subscription 


95 


105 


c5 


99 


draft-liess-dispatch-alert-info-urns-02 [133]: Alert-Info URNs 
for the Session Initiation Protocol 


96 


106 





c1 : m in case of roaming NNI between home and visited IIVIS, else o 

c2: m in case of roaming NNI between home and visited IMS, else n/a 

c3: in case of roaming NNI between home and visited IMS, else n/a 

c4: m in case of trust relationship between the interconnected networks, else n/a 

c5: m in the case the REFER request is supported, else n/a 


NOTE 1 : The item numbering corresponds to the one provided in Table A. 4 in [5] 
NOTE 2: The item numbering corresponds to the one provided in Table A.I 62 in [5] 
NOTE 3: A common URI namespace is required to apply this feature on the ll-NN 



Table 6.1.3.2: Key to notation codes for major capabilities 



Notation 
code 


Notation name 


Explanation 


m 


mandatory 


The capability shall be supported at ll-NNI. 

SIP message relating to this capability shall be sent over the ll-NNI if received from 

the serving network, unless they also make use of other unsupported capabilities. 

SIP headers or other information elements relating to this capability shall be passed 

over the ll-NNI if received from the sending side. 

This does not imply that network elements inside the serving network or served 

network or user equipment connected to these networks shall support this capability. 





optional 


The capability may or may not be supported at ll-NNI. The support of the capability is 
provided based on bilateral agreement between the operators. 


n/a 


not applicable 


It is impossible to use/support the capability at the ll-NNI. 


c 
<integer> 


conditional 


The support of the capability ("m", "o" or "n/a") depends on the support of other 
optional or conditional items. <integer> is the identifier of the conditional expression. 



6.2 Control Plane Transport 



6.2.1 General 

The control plane transport of the II-NNI shall comply with Clause 4.2 A of 3GPP TS 24.229 [5]. 

Support of SCTP as specified in IETF RFC 4168 [27] is optional for an IBCF connected by ll-NNI. Nevertheless this 
option is favourable if the operators would like to improve reliability over the Ici. 



User plane Interconnection 



7.1 



Media and Codec 



For "end-to-end" media session involving the II-NNI, the SIP/SDP codec negotiation procedure can be applied between 
IM CN subsystems using different media codecs. It is possible that the end-to-end codec negotiation could fail because 
no common codec could be supported by the UEs, in particular for voice services. 

To enhance interoperability, the IBCF, the MRFC, or other IMS network entities can interfere with the end-to-end 
codec negotiation to offer additional codec(s) available via transcoding, or to remove codecs. The IBCF can configure 
an attached TrGW to transcode, and the MRFC can configure an attached MRFP to transcode. 
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Codecs applicable at the NNI may be a subject of interworking agreements. 

NOTE: Possible codecs which could be used at the II-NNI are described in 3GPP TS 26. 1 14 [1 1] and ETSI TS 

181 005 [12]. 

However, to avoid that transcoding is performed several times, applicable codecs at the NNI should be restricted as 
little as possible. 

NOTE: Transcoding can be performed in an IMS network serving an SDP offerer or in an IMS network serving 
an SDP answerer. To avoid that transcoding is performed multiple times, inter-operator agreements can 
clarify if it is preferred that IMS network serving an SDP offerer or IMS network serving an SDP 
answerer modify an SDP offer to offer transcoding. 

If the IBCF performs media transcoding control, it shall apply the related procedures in 3GPP TS 24.229 [5]. 

7.2 User Plane Transport 

The user plane transport of the II-NNI may use the protocols listed in Table 7.2.1. The used protocols to transport media 
are negotiated by means of SDP offer/answer. 

Table 7.2.1 : Supported transport-level RFCs to be described in SIP/SDP messages 



Item 


RFC 


Title 


Support 


1 


RFC 3550 


RTP: A Transport Protocol for Real-Time Applications 


Mandatory 


2 


RFC 768 


User Datagram Protocol 


Mandatory 


3 


RFC 3551 


RTP Profile for Audio and Video Conferences with Minimal 
Control 


Mandatory 


4 


RFC 3556 


Session Description Protocol (SDP) Bandwidth IVIodifiers for 
RTP Control Protocol (RTCP) Bandwidth 


Mandatory 


5 


RFC 4585 


Extended RTP Profile for Real-time Transport Control Protocol 
(RTCP) - Based Feedback (RTP/AVPF) 


Optional 
(N0TE1) 


6 


RFC 793 


Transmission Control Protocol 


Optional 
(NOTE 2) 


NOTE 1 : used by MTSI, as indicated in 3GPP TS 26.1 14 [11] 
NOTE 2: used for IVISRP service 



8 



Numbering, Naming and Addressing 



The following URI formats in SIP messages may be applied at the Ici as standardized in 3GPP TS 24.229 [5]: 

• SIP URI defined in IETF RFC 326 1 [ 1 3] ; 

• tel URI defined in IETF RFC 3966 [ 14] ; 

• IM URI defined in IETF RFC 3860 [15]; 

• PRES URI defined in IETF RFC 3859 [16]. 

Moreover, in case of MSRP sessions passing through the II-NNI, the MSRP URI may be also used at the Ici in the SDP 
exchange, following the formats defined in IETF RFC 4975 [17]. 

According to TS 24.229, the IBCF acting as an exit or entry point in the IMS network supports these URI formats. 

These URI formats shall be supported at the II-NNI.. Other URI formats may be supported over the II-NNI depending 
on the operators" agreements. 

A global number as defined in IETF RFC 3966 [14] shall be used in a tel-URI or in the user portion of a SIP URI with 
the user=phone parameter when conveyed via a non-roaming interface in the Request-URI and in the P-Asserted- 
Identity header field, except when agreement exists between the operators to also allow other kinds of numbers. 
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NOTE 1 : In a SIP URI the user portion of the Request-URI represents a telephone number only if the SIP URI 
includes the user=phone parameter. 

NOTE 2: Agreements can exist between operators to allow non-global number (e.g. national service numbers. 

business trunking numbers, or private numbers) at a non-roaming II-NNI. A SIP URI with such a number, 
a user=phone parameter, and a phone-context parameter agreed between the operators can then be used. 

NOTE 3: 3GPP TS 24.229 [5] allows to restrict the number within a SIP Request-URI with user=phone parameter 
at a non-roaming II-NNI to be a global number (i.e. E.164 in international format) via an appropriate 
Application Server. Suitable configuration by the operator is needed to achieve the desired modification 
of the format. 

NOTE 4: The allowed phone number formats in the P-Asserted-Identity header field of a served user are configured 
by the operator. According to 3GPP TS 23.003 [35], international E.164 format is used within a P- 
Asserted-Identity header field. 

NOTE 5: The global number format usage within a SIP Request-URI with the user=phone parameter at a non- 
roaming II-NNI allows the terminating network to find the called subscriber, via HSS interrogation, 
without any further number translation and thus improves the success of the interconnection between IMS 
Operators. 



IP Version 



The network elements interconnected by means of the II-NNI may support IPv4 only, IPv6 only or both. 

The support of one or both of the IP versions is an operator option and should be based on bilateral agreement. 

In case IPv4 and IPv6 networks are interconnected, the involved IBCFs and TrGWs shall apply the IP version 
interworking procedures as indicated in 3GPP TS 29.162 [8]. 



10 Security 



The supported security mechanisms for IP signalling transport over II-NNI interfaces are described in 3GPP TS 33.210 
[10]. 



1 1 Charging 



The accounting information to be supported over the Ici is described in 3GPP TS 32.260 [29]. It shall be configurable 
by the operator to use or not the accounting mechanisms provided by the IBCF. 



12 Supplementary services associated with the IIVIS 
multimedia telephony communication service 

12.1 General 

In order to assure the end-to-end service interoperability through the Inter-IMS Network to Network Interface (II-NNI), 
associated supplementary services of the multimedia telephony communication service may be supported on the II-NNI 
between the two IMS networks. If they are supported, the related procedures from the 3GPP TS 22.173 [30], the 
protocol details from the 3GPP TS 24.173 [31] and specifications referenced in the later specification shall be applied 
with the following restrictions due to the crossing of the II-NNI. 
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12.2 Malicious Communication IDentification (IVICID) 

Service specific requirements in accordance with 3GPP TS 24.616 [33] shall be supported over the II-NNI. 

The P-Asserted-ldentity header field shall be supported at the 11-NNI. 

The INFO request and the 200 (OK) response to the INFO request containing the "application/vnd.etsi.mcid+xml" 
MIME body defined in 3GPP TS 24.616 [33] may be supported at the 11-NNl. 

If a network terminating the dialog supports MCID, the terminating network shall only deliver the MCID request in the" 
application/ mcid+xm 1 " MIME body, as specified in the 3GPP TS 24.616 [33], if an agreement to use the MCID 
supplementary service according to the 3GPP TS 24.616 [33] exists with the network originating the dialog and if the 
INVITE request received by the terminating network does not contain the information of the originating party. 

NOTE: The IBCF and the AS in the terminating network interact to deliver the MCID request only if an 

agreement to use the MCID supplementary service exists, as specified in 3GPP TS 24.616 [33] and 3GPP 
TS 24.229 [5]. 

The originating network and the terminating network shall have a bilateral agreement to support transportation of the 
minimum information specified in subclause 4.5.2.5.0 of the 3GPP TS 24.616 [33] between the networks. 

12.3 Originating Identification Presentation (OIP) and Originating 
Identification Restriction (OIR) 

Service specific requirements in accordance with 3GPP TS 24.607 [32] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and 
"critical" shall be supported at the II-NNI. 

NOTE 1 : P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 

will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered 
when passing through the II-NNI according to 3GPP TS 24.229 [5]. Where no trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, the P-Asserted-Identity header field 
will be removed by the IBCF of the originating network prior passing through the II-NNI according to the 
3GPP TS 24.229 [5]. The IBCF determines whether to remove the P-Asserted-Identity header field 
according to procedures in 3GPP TS 24.229 [5] referencing IETF RFC 3325 [44]. 

The option tag "from-change" in the Supported header field should be supported at II-NNI. 

NOTE 2: The From header field cannot be altered when passing through the II-NNI and will be passed 

transparently by the IBCF. If a request is received by the terminating network and the application of the 
OIR service is required with the value "user" for the Privacy header field then the From header field will 
be anonymised in accordance with IETF RFC 3323 [34] by the terminating network. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.4 Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) 

Service specific requirements in accordance with 3GPP TS 24.608 [113] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field with values "id", "user", "none", "header" and 
"critical" shall be supported at the II-NNI. 

NOTE : P-Asserted-Identity header fields are intended for end-to-end operation. Removal of such header fields 

will impact the intended end-to-end operation between the end users. Where a trust relationship exists on 
the P-Asserted-Identity header field between the two IMS networks, this header field cannot be altered 
when passing through the II-NNI according to 3GPP TS 24.229 [5]. 
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Where no trust relationship exists on the P-Asserted-Identity header field between the two IMS networks, 
the P-Asserted-Identity header field will be removed by the IBCF of the originating network prior passing 
through the II-NNI according to the 3GPP TS 24.229 [5]. The IBCF determines whether to remove the P- 
Asserted-Identity header field according to procedures in 3GPP TS 24.229 [5] referencing IETF RFC 

3325 [44]. 

12.5 Anonymous Communication Rejection (ACR) 

Service specific requirements in accordance with 3GPP TS 24.611 [107] shall be supported over the II-NNI. 

The P-Asserted-Identity header field and the Privacy header field shall be supported at the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 433 (Anonymity Disallowed) shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.6 Communication Diversion (CDIV) 

Service specific requirements in accordance with 3GPP TS 24.604 [1 17] shall be supported over the II-NNI. 

NOTE 1 : The support of the Diversion header field not adopted in 3GPP TS 24.604 requires bilateral agreement 
between the operators. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The Privacy header field with value "history" shall be supported at the II-NNI. 

The History-Info header field as described by 3GPP TS 24.604 [117] and the Cause-Codes as defined by the 
IETF RFC 4458 [118] shall be supported over the II-NNI. 

The response code 181 (Call Is Being Forwarded) shall be supported at the II-NNI. 

The SUBSCRIBE requests with the event package name "comm-div-info" and the NOTIFY request procedure as 
specified in IETF RFC 3265 [20] and 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI if CDIVN is 
provided. 

The MESSAGE request procedure as specified in IETF RFC 3428 [19] and 3GPP TS 24.229 [5] should be supported at 
the roaming II-NNI if CDIVN is provided. 

NOTE 2: The content of the MESSAGE request is operator specific. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.7 Communication Waiting (CW) 

Service specific requirements in accordance with 3GPP TS 24.615 [37] shall be supported over the II-NNI. 

The 'appHcation/vnd.3gpp.cwH-xmr MIME body defined in 3GPP TS 24.615 [37] in the INVITE request shall be 
supported at the roaming II-NNI. 

The Alert-Info header field set to "urn:alert:service:call-waiting" in a 180 (Ringing) response shall be supported at the 
II-NNI. 

As a network option, in case of expiry of the CW timer, the response code 480 (Temporarily Unavailable) including a 
Reason header field set to cause 19 shall be supported at the non-roaming II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 
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12.8 Communication HOLD (HOLD) 

Service specific requirements in accordance with 3GPP TS 24.610 [36] shall be supported over the II-NNI. 

NOTE: The support of an alternative method not adopted in 3GPP TS 24.610 requires bilateral agreement 
between the operators and is outside the scope of the present document. 

Procedures as described in subclause 12.21.3 are used to provide announcements. 

12.9 IVIessage Waiting Indication (IVIWI) 

Service specific requirements in accordance with 3GPP TS 24.606 [1 12] shall be supported over the Il-NNl. 

The event package name "message-summary" according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] in the 
SUBSCRIBE request shall be supported at the roaming 11-NNl. 

The application/simple-message-summary+xml MIME body described in 3GPP TS 24.606 [112] in the NOTIFY 
request shall be supported at the roaming II-NNI. 

12.10 Communication Barring (CB) 

12.10.1 Incoming Communication Barring (ICB) 

Service specific requirements in accordance with 3GPP TS 24.61 1 [1 14] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header field as described in 3GPP TS 24.61 1 [1 14] shall be 
supported at the II-NNI. 

A Reason header field as described in 3GPP TS 24.611 [114] included in the BYE request shall be supported at the II- 
NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.10.2 Outgoing Communication Barring (OCB) 

Service specific requirements in accordance with 3GPP TS 24.611 [114] shall be supported over the II-NNI. 

Procedures as described in subclause 12.21.2 are used to provide announcements. 

The response code 603 (Decline) including a Reason header field as described in 3GPP TS 24.61 1 [1 14] shall be 
supported at the roaming 11-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.1 1 Completion of Communications to Busy Subscriber (CCBS) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the II-NNI. 

The response code 486 (Busy Here) containing a Call-Info header field with a "purpose" header field parameter set to 
"call-completion" and the "m" parameter set to "BS" shall be supported at the non-roaming II-NNI. 

For invoking and revoking of the CCBS supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 
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Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shal be 1 supported at the roaming II-NNI. 

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [110] should be 
supported at the roaming II-NNI. 

NOTE 1 : 3"* party call control procedures can be used when the REFER request is not supported at the II-NNI. 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' 
and the m parameter set to "BS" shall be supported at the non-roaming interface II-NNI. 

The Request-URI with the "m" SIP URI parameter with a value set to "BS" and the Call-Info header field with a 
purpose parameter set to 'call-completion' and the "m" parameter set to "BS" in the INVITE method shall be supported 
at the non-roaming II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.12 Completion of Communications by No Reply (CCNR) 

Service specific requirements in accordance with 3GPP TS 24.642 [109] shall be supported over the II-NNI. 

The response code 180 (Ringing) containing a Call-Info header field with a purpose parameter set to 'call-completion' 
and the "m" parameter set to "NR" shall be supported at the non-roaming interface. 

For invoking and revoking of the CCNR supplementary service, announcement procedures shall be used to provide 
announcements and inband-interaction procedures as described in subclause 12.21.2 shall be supported at the roaming 
II-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported at the roaming II-NNI. 

Basic call procedures and in case of a call-completion recall initiated by a REFER request, normal REFER method 
handling procedures according to 3GPP TS 24.229 [5] shall be supported at the roaming II-NNI. 

As a network option the special REFER request handling procedures according to 3GPP TS 24.628 [110] should be 
supported at the roaming II-NNI. 

NOTE 1 : 3rd party call control procedures can be used when the REFER request is not supported at the II-NNI. 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The SUBSCRIBE and NOTIFY methods according to IETF RFC 3265 [20] and 3GPP TS 24.229 [5] containing the 
event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' 
and the m parameter set to "NR" shall be supported at the non-roaming interface II-NNI. 

The Request-URI with the "m" SIP URI parameter with a value set to "NR" and the Call-Info header field with a 
purpose parameter set to 'call-completion' and the "m" parameter set to "NR" in the INVITE method shall be supported 
at the non-roaming II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.13 Explicit Communication Transfer (ECT) 

Service specific requirements in accordance with 3GPP TS 24.629 [1 16] shall be supported over the II-NNI. 

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] 
and the NOTIFY method containing an " application/sipfrag " MIME body shall be supported at the II-NNI for call 
transfer without third party call control. 

The REFER method, the Referred-By header field and the Replaces header field as specified in 3GPP TS 24.629 [116] 
and the NOTIFY method containing an " application/sipfrag " MIME body shall be supported at the roaming II-NNI for 
call transfer with third party call control. 



£75/ 



3GPP TS 29.1 65 version 9.5.0 Release 9 30 ETSI TS 1 29 1 65 V9.5.0 (201 1 -01 ) 

12.14 Customized Alerting Tone (CAT) 

Service specific requirements in accordance with 3GPP TS 24.182 [129] shall be supported over the 11-NNl. 

The P-Early -Media header field in as described in 3GPP TS 24.182 [129] shall be supported at the 11-NNI. 

The response code 183 (Session Progress) including a P-Early-Media header field shall be supported over the 11-NNI. 

The response code 199 (Early Dialog Terminated) shall be supported over the 11-NNI. 

The Supported header field and the Require header field with "early-session" option-tag may be supported at the II- 

NNI. 

An " application/sdp " MIME body with the Content-Disposition set to "early-session" as specified in IETF RFC 3959 
[96] may be supported at 11-NNI. 

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] shall be supported at the II-NNI. 

NOTE: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the 
control plane. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming 11-NNI. 

12.15 Customized Ringing Signal (CRS) 

Service specific requirements in accordance with 3GPP TS 24.183 [98] shall be supported over the 11-NNI. 

An Alert-Info header field in the initial INVITE request containing an URI followed by a URN "urn:alert:service:crs" 
shall be supported at the 11-NNI. 

A Contact header field in the initial INVITE request containing a "g.3gpp.crs" feature tag may be supported at the II- 
NNI. 

The Supported header field and the Require header field with "early-session" option-tag may be supported at the II- 
NNI. 

An " application/sdp " MIME body with the Content- Disposition set to "early-session" as specified in IETF RFC 3959 
[96] may be supported at 11-NNI. 

The SIP INFO mechanism for DTMF transport, as defined in 3GPP TS 24.229 [5] may be supported at the II-NNI. 

NOTE: For telephone-event based DTMF transport, the DTMF digits are sent as media and not visible in the 
control plane. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.16 Closed User Group (CUG) 

Service specific requirements in accordance with 3GPP TS 24.654 [103] shall be supported over the II-NNI. 

The "application/vnd.etsi.cug-Hxml" MIME body as specified 3GPP TS 24.654 [103] shall be supported in INVITE 
requests at the II-NNI. 

NOTE: If no agreement between the originating network and the terminating network exists to support the CUG 
supplementary service the INVITE request is rejected as described in IETF RFC 5621 [89] when the 
"handling" parameter in the Content-Disposition of the " application/vnd.etsi.cug-nxml" MIME body is set 
to "required". 

The 403 (Forbidden) response, the 603 (Decline) response and the 500 (Server Internal Error) response shall be 
supported at 11-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 
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12.17 Personal Network Management (PNM) 

Service specific requirements in accordance with 3GPP TS 24.259 [99] shall be supported over the II-NNI. 

The Contact header field of the REGISTER request containing the g.3gpp.iari_ref feature tag with the value urn:urn- 
7:3gpp-application.ims.iari.pnm-controller shall be supported at the roaming II-NNI. 

The Accept-Contact header field containing a g. 3 gpp.iari_ref feature tag with the value urn:urn-7:3gpp- 
application.ims.iari.pnm-controller shall be supported at the II-NNI. 

The History-Info header field and Supported header field containing the "histinfo" option tag as described by 3GPP TS 
24.259 [99] shall be supported at II-NNI. 

12.18 Three-Party (3PTY) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE 1 : The requirements below can be relaxed by bilateral agreements between operators. 

The requirements for the 3PTY supplementary service are the same as for the CONE supplementary service specified in 
subclause 12.19 with the following additional requirement: 

If a REEER request is supported at the II-NNI, a Replaces header field in the header portion of the SIP URI of 
the Refer-to header field of the REEER request shall also be supported at II-NNI. 

NOTE 2: Subclause 12.19 describes the conditions for the support of the REEER request. 

12.19 Conference (CONF) 

Service specific requirements in accordance with 3GPP TS 24.605 [105] shall be supported over the II-NNI. 

NOTE 1 : The requirements below can be relaxed by bilateral agreements between operators. 

The REFER request shall be supported at the roaming II-NNI in the direction from visited to home network. Based on 
inter-operator agreement, the REFER request may be supported at II-NNI between home networks, and at the roaming 
II-NNI in the direction from home network to visited network. 

NOTE 2: If the REEER request is not supported at the II-NNI between home networks, or at the roaming II-NNI in 
the direction from home network to visited network, an attempt of an UE to send the REEER directly to 
peers to invite them to a conference without involvement of the conference focus can fail over such an II- 
NNI. However such failures can also occur if a peer is located in a circuit switched network, or if a peer 
does not support the REEER method. An operator can avoid such failures by configuring an AS to 
convert the REEER to an INVITE, as detailed in 3GPP TS 24.628 [38]. Information on security risks 
associated with the REEER request is provided within the security consideration" of IETF RFC 3515 
[22]. 

NOTE 2: A REFER request can be rejected by IBCF based on operator policy as specified by 3GPP TS 24.229 [5]. 

The application/resource-listsH-xml MIME body shall be supported at the roaming II-NNI. 

The Referred-By header field in the INVITE request shall be supported at the II-NNI. 

The "isfocus" feature parameter indicated in Contact header field of the INVITE request and in the 200 (OK) response 
shall be supported at the II-NNI. 

The SUBSCRIBE request including the "conference" event package name in the Event header field and the NOTIFY 
request procedures according to 3GPP TS 24. 147 [106] shall be supported at the II-NNI. 

12.20 Flexible Alerting (FA) 

Service specific requirements in accordance with 3GPP TS 24.239 [101] shall be supported over the II-NNI. 
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The 486 (Busy Here) response code shall be supported at the II-NNI. 

SIP based user configuration as described in 3GPP TS 24.238 [100] shall be supported at the roaming II-NNI. 

12.21 Announcements 

12.21.1 General 

Announcements may be provided during the establishment of a communication session or during an established 
communication session. Both of them shall be managed over the II-NNI. 

1 2.21 .2 Providing announcements during \he establisiiment of a 
communication session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 

The P-Early-Media header authorizing early media as defined in IETF RFC 5009 [12] during the establishment of a 
communication fields shall be supported at the II-NNI. 

The Alert-Info header in the 1 80 (Ringing) response to the INVITE request during the establishment of a 
communication, should be supported at the II-NNI. 

NOTE: The IBCF can decide to remove the Alert-Info header field if required by local policy. 

1 2.21 .3 Providing announcements during an establisined communication 
session 

Procedures as described in 3GPP TS 24.628 [38] are used to provide announcements. 

In case of provision of an announcement to a user over the II-NNI during an established communication, the Call-Info 
header field in a re-INVITE request should be supported at the II-NNI. 

NOTE 1 : An alternative method to provide announcements is to use the existing media stream. 

NOTE 2: The IBCF can decide to remove the Call-Info header field if required by local policy. 

1 2.22 Advice of Charge (AOC) 

Service specific requirements in accordance with 3GPP TS 24.647 [122] shall be supported over the II-NNI. 

The Accept header field with "application/vnd.etsi.aocH-xml" shall be supported at the roaming II-NNI. 

The INVITE method containing an application/vnd.etsi.aocH-xml" MIME body shall be supported at the roaming II- 
NNI. 

Ixx provisional responses and the 200 (OK) response to the initial INVITE request containing an 
application/vnd.etsi.aocH-xml MIME body shall be supported at the roaming II-NNI. 

The INFO method containing an application/vnd.etsi.aocH-xml MIME body shall be supported at the roaming II-NNI. 

The response code 504 (Server Time-out) shall be supported at the II-NNI. 

A Reason header field with a reason value with the protocol set to "SIP" and the cause set to "504" and a reason value 
with the protocol set to "Q.850" and the cause set to "31" in the BYE method shall be supported at the II-NNI. 

An application/vnd.etsi.aocH-xml MIME body in the BYE request or the final response to the BYE request shall be 
supported over the roaming II-NNI. 
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Annex A (informative): 
Summary of SIP header fields 

A summary of the SIP header fields to be used in case of interconnection by using II-NNI is proposed in Table A.l. 

The starting point is the sending behaviour described for proxy and UA roles in Annex A of 3GPP TS 24.229 [5]. In 
case of misalignment between Table A.l and the behaviour described in 3GPP TS 24.229 [5], the behaviour in 3GPP 
TS 24.229 [5] has the precedence. In case a header field is not described in Table A.l and it is described in [5], the 
description in 3GPP TS 24.229 [5] is applicable over II-NNI. 

The notation of the codes used for the SIP headers listed in table A. 1 has a different meaning to the one proposed for the 
SIP messages. The definition of these terms is provided in table A.2. 
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Table A.I : Supported header fields 



Item 


Header field 


Ref. 


ll-NNI 


1 


Accept 


[51 


m 


2 


Accept-Contact 


[51 


m 


3 


Accept-Encoding 


[51 


m 


4 


Accept-Language 


[51 


m 


4a 


Accept-Resource-Priority 


[51 





5 


Alert- Info 


[51 





6 


Allow 


[51 


m 


7 


Allow-Events 


[51 


m 


8 


Authentication-Info 


[51 


m 


9 


Authorization 


[51 


m 


9a 


Answer-Mode 


[51 





10 


Call-ID 


[51 


m 


11 


Call-Info 


[51 


m 


12 


Contact 


[51 


m 


13 


Content-Disposition 


[51 


m 


14 


Content-Encoding 


[51 


m 


15 


Content-Language 


[51 


m 


16 


Content-Length 


[51 


m 


17 


Content-Type 


[51 


m 


18 


Cseq 


[51 


m 


19 


Date 


[51 


m 


20 


Error-Info 


[51 





21 


Expires 


[51 


m 


21a 


Flow-Timer 


[51 


m on roaming NNI between home and visited IMS, else o 


22 


Event 


[51 


m 


23 


From 


[51 


m 


24 


Geolocation 


[51 


m 


24a 


Geolocation-Error 


[51 


m 


25 


History-Info 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 4) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


25d 


Info-Package 


[51 





26 


In-Reply-To 


[51 





27 


Join 


[51 





27a 


Max-Breadth 


[51 


n/a 


28 


Max-Forwards 


[51 


m 


29 


Min-Expires 


[51 


m 


30 


MIME-Version 


[51 


m 


31 


Min-SE 


[51 


m 


32 


Organization 


[51 


m 


33 


P-Access-Network- 1 nf o 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 2) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


33a 


P-Answer-state 


[51 





34 


P-Asserted-ldentity 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 1) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


35 


P-Asserted-Service 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 5) 


m in case of a trust relationship between the 
interconnected networks, else n/a 


35a 


P-Associated-URI 


[51 


m on roaming NNI between home and visited IMS, else n/a 


36 


P-Called-Party-ID 


[51 


m on roaming NNI between home and visited IMS, else n/a 


37 


P-Charging-Function- 
Addresses 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 7) 


n/a 


38 


P-Charging-Vector 


sub-clause 
6.1.1.3.1 


m in case of a trust relationship between the interconnected 
networks, else n/a 
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Item 


Header field 


Ref. 


ll-NNI 






(Table 6.2, 
item 6) 




38a 


P-Debug-ld 


[51 





39 


P-Early-IVIedia 


[51 


m 


40 


P-IVIedia-Authorization 


[51 


n/a 


41 


P-Preferred-ldentity 


[5] 


n/a 


42 


P-Preferred-Service 


[5] 


m on roaming NNI between home and visited IMS, else n/a 


43 


P-Private-Network-lndication 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 9) 


m on roaming NNI between home and visited IMS, else o 


44 


P-Profile-Key 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 8) 


on roaming NNI between home and visited IMS, else n/a 


45 


P-Served-User 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 10) 


m on roaming NNI between home and visited IMS, else n/a 


46 


P-User-Database 


[51 


n/a 


47 


P-Visited-Network-ID 


[5] 


m on roaming NNI between home and visited IMS, else n/a 


47a 


Path 


[51 


m on roaming NNI between home and visited IMS, else n/a 


47b 


Permission-Missing 


[51 




48 


Priority 


[51 





48a 


Priv-Answer-Mode 


[51 





49 


Privacy 


[51 


m 


50 


Proxy-Authenticate 


[5] 


m on roaming NNI between home IMS and visited IMS, else 
n/a 


51 


Proxy-Authorization 


[5] 


m on roaming NNI between home IMS and visited IMS, else 
n/a 


52 


Proxy- Require 


[51 


m 


52a 


RAck 


[51 


m 


53 


Reason 


[51 and sub- 
clause 
6.1.1.3.1 
(Table 6.2, 
item 11) 


when in a request. 

When in a response, m in case of a trust relationship 

between the interconnected networks, else n/a 


54 


Record-Route 


[51 


m 


54a 


Recv-lnfo 


[51 





55 


Referred-By 


[51 


m 


55a 


Refer-Sub 


[5] 


m in the case the REFER request is supported, else n/a 


55b 


Refer-To 


[5] 


m in the case the REFER request is supported, else n/a 


56 


Reject-Contact 


[51 


m 


57 


Replaces 


[51 





58 


Reply-To 


[51 





59 


Request-Disposition 


[51 


m 


60 


Require 


[51 


m 


61 


Resource-Priority 


sub-clause 
6.1.1.3.1 
(Table 6.2, 
item 3) 


m in case of a trust relationship between the interconnected 
networks, else n/a 


62 


Route 


[51 


m 


62a 


RSeq 


[51 


m 


63 


Security-Client 


[5] 


n/a 


63a 


Security-Server 


[51 


n/a 


64 


Security-Verify 


[51 


n/a 


65 


Server 


[51 





65a 


Service-Route 


[51 


m on roaming NNI between home and visited IMS, else n/a 


65b 


Session-ID 


[51 





66 


Session-Expires 


[51 


m 


66a 


SIP-ETag 


[5] 


m in the case the PUBLISH request is supported, else n/a 


66b 


SIP-lf-Match 


[5] 


m in the case the PUBLISH request is supported, else n/a 


67 


Subject 


[51 





67a 


Subscription-State 


[51 


m in the case the NOTIFY request Is supported, else n/a 
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Item 


Header field 


Ref. 


ll-NNI 


68 


Supported 


[5] 


m 


69 


Timestamp 


[5] 


m 


70 


To 


[51 


m 


71 


Trigger-Consent 


[51 


m 


71a 


Unsupported 


[51 


m 


72 


User-Agent 


[51 


m 


73 


User-to-User 


[51 





74 


Via 


[51 


m 


75 


Warning 


[51 





76 


www-Authenticate 


[51 


m on roaming NNI between lionne and visited IIVIS, else n/a 



Table A.2: Key to notation codes for SIP header fields 



Notation 
code 


Meaning 


m 


The SIP header field is applicable at ll-NNI. 

Supporting a SIP header field at the ll-NNI means that this header field 
is passed through the IBCF. It does not imply that network elements 
inside the serving and served networks or user equipment connected 
to these networks shall support this header field, where 3GPP TS 
24.229 [51 is applied. If specified in 3GPP TS 24.229, the IBCF 
modifies the SIP header field. 





The applicability of SIP header field at ll-NNI depends on bilateral 
agreement between the operators. 


n/a 


It is impossible to use the SIP header field at the ll-NNI. This header 
field could be discarded by the IBCF. 
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3 
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004 


1 
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8.0.0 


8.1.0 
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TSG#43 
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007 


2 
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8.0.0 


8.1.0 


05/2009 


TSG#44 
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008 


4 


Use of E.I 64 number at the ll-NNI 


8.1.0 


8.2.0 


05/2009 


TSG#44 


CP-090341 


009 


4 


Correction to SIP headers table 


8.1.0 


8.2.0 


09/2009 


TSG#45 


CP-090576 


017 


1 


Removal of left-over text from TS drafting phase and update of a 
reference 


8.2.0 


8.3.0 


09/2009 


TSG#45 


CP-090576 


018 


2 


Applicability of SIP headers for roaming ll-NNI 


8.2.0 


8.3.0 


09/2009 


TSG#45 


CP-090576 


019 


1 


Application level gateway usage to enable communication from 
private IP address space 


8.2.0 


8.3.0 


09/2009 


TSG#45 


CP-090576 


020 


3 


Codecs at the NNI 


8.2.0 


8.3.0 


09/2009 


TSG#45 


CP-090584 


Oil 


4 


Major capabilities on ll-NNI 


8.3.0 


9.0.0 


09/2009 


TSG#45 


CP-090584 


013 


4 


Management of SIP headers over ll-NNI in presence of trust or no 
trusted relationship (VI) 


8.3.0 


9.0.0 


09/2009 


TSG#45 


CP-090584 


015 


4 


Requirements for the end-to-end interoperability of supplementary 
services 


8.3.0 


9.0.0 


09/2009 


TSG#45 


CP-090584 


016 


3 


Deletion of the note about the normalization of phone numbers 


8.3.0 


9.0.0 


12/2009 


TSG#46 


CP-090854 


021 


5 


Requirements for HOLD service over ll-NNI 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


022 


5 


Requirements for CW service over ll-NNI 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090844 


024 


3 


Aligning references to P-Asserted-Service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090844 


026 




Annex A header updated with Answer-Mode, Priv-Answer-Mode 
and P-Answer-State 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


031 


6 


Filling of the table about major capabilities on ll-NNI 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


032 


1 


Customized Ringing Signal (CRS) modification 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


033 


2 


Completing the Personal Network Management (PNM) 
supplementary service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


034 


1 


Aligning existing supplementary services 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


035 


1 


Completing the Flexible Alerting (FA) supplementary service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


036 


1 


Completing the Closed User Group (CUG) supplementary service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


037 


3 


Completing the Three-Party (3PTY) and Conference (CONF) 
supplementary services 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


038 


3 


Completing the Anonymous Communication Rejection (ACR) 
supplementary service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


039 


3 


Completing Completion of Communications to Busy Subscriber 
(CCBS) and Completion of Communications by No Reply (CCNR) 
supplementary services 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


040 




Completing Message Waiting Indication (MWI) supplementary 
service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


041 


1 


Completing the Terminating Identification Presentation (TIP) and 
Terminating Identification Restriction (TIR) needs to be completed. 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


042 


3 


Completing the Communication Barring (CB) supplementary 
service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


043 


2 


Completing Explicit Communication Transfer (ECT) 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


044 


3 


Completing Communication Diversion (CDIV) supplementary 
services 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090854 


046 


2 


Deletion of an editors note on OIR service 


9.0.0 


9.1.0 


12/2009 


TSG#46 


CP-090844 


047 


3 


Annex A header updated 


9.0.0 


9.1.0 


03/2010 


TSG#47 


CP-1 00077 


051 


2 


Format of Request URI 
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03/2010 
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CP-1 00077 
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2 


MSC Server enhanced for ICS missing in architecture 
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03/2010 
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AOC added to supplementary services 
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9.2.0 


03/2010 
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059 




CPC and OLI IETF reference update 


9.1.0 


9.2.0 


03/2010 


TSG#47 


CP-1 00087 


060 


3 


CPC and OLI and trust domain 


9.1.0 


9.2.0 


03/2010 


TSG#47 


CP-1 00087 


061 


1 


Modifying CUG interactions 


9.1.0 


9.2.0 


03/2010 


TSG#47 


CP-1 00087 


062 




Correcting minor errors 


9.1.0 


9.2.0 


03/2010 


TSG#47 


CP-1 00087 


063 


4 


Updating Major Capability according to latest 24.229 


9.1.0 


9.2.0 
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TSG#47 


CP-1 00087 


064 


1 


Major Capabilities revision 2 
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9.2.0 
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067 


1 


Table 6.2 update 
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03/2010 


TSG#47 
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068 


1 


IVIodification of OIP/OIR paragraph description (R9 29.165) 


9.1.0 


9.2.0 


03/2010 


TSG#47 


CP-1 00087 


071 


1 


References numbers update (R9 29.165) 


9.1.0 


9.2.0 


06/2010 


TSG#48 


CP-100319 


073 


1 


Tfie Session-ID added to annex A 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


077 


2 


Correcting incorrect interface name 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


079 


2 


Supported URI formats also based on operator agreements 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


080 


2 


Customized Alerting Tone (CAT) 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


081 


2 


Customized Ringing Signal (CRS) 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


082 


1 


Correcting miscellaneous errors 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


084 


2 


Applicability of "critical" privacy value 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


085 




Making Alert-Info not mandatory 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


086 


1 


Draft-jofinston-sipping-cc-uui reference updated to new version 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


087 


2 


Correcting references for removal of P-Asserted-ldentity 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


091 


2 


Correction of Mayor Capabilities 


9.2.0 


9.3.0 


06/2010 


TSG#48 


CP-100319 


093 


2 


Usage of "Refer" for conferencing and 3PTY 


9.2.0 


9.3.0 


09/2010 


TSG#49 


CP-1 00553 


095 


2 


Support of REFER checked by entry IBCF 


9.3.0 


9.4.0 


09/2010 


TSG#49 


CP-1 00545 


098 


2 


Removing unnecessary normative text 


9.3.0 


9.4.0 


09/2010 


TSG#49 


CP-1 00553 


100 


2 


CCBS and CCNR and the m-parameter 


9.3.0 


9.4.0 


09/2010 
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CP-1 00553 


103 


1 


Correcting references 
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105 




Adding missing "history" privacy value to CDIV 
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3 


MCID and identity information transfer clarification 
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2 


Correcting name of the Authenticate header field and the 
applicability over ll-NNI 
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CP-1 00553 
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1 


Aligning Major Capabilities Table with 24.229 
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TSG#50 


CP-1 00781 
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2 


Aligning annex A with Major Capabilities Table 
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125 
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1 


IBCF and URI formats 
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1 


Roaming and non-roaming definition added 
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2 


Refer-Sub and Refer-To missing in annex A 
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2 


Supplementary services corrections 
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12/2010 


TSG#50 


CP-1 00781 
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MCID and ACR 
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